跳到主要内容

利用kubeadm部署kubernetes集群

1.kubeadm 部署工具​

kubeadm 是kubernetes 集群全生命周期管理工具，可用于实现集群的部署、升级/降级及卸载等。

kubeadm 的核心工具是 kubeadm init 和 kubeadm join ，前者用于创建新的控制平面节点，后者则用于将节点快速连接到指定的控制平面。

kubeadm init: 这个命令用于初始化一个新的 Kubernetes 集群的控制平面节点。

在运行这个命令后，它将自动生成一个初始的控制平面配置，创建必要的证书和密钥，以及启动必要的核心组件，如 etcd、API Server、Controller Manager 和 Scheduler。

kubeadm join: 这个命令用于将工作节点快速连接到已经初始化的 Kubernetes 控制平面。

当你运行 kubeadm init 后，它会生成一个令牌 (token) 和一个哈希 (hash)，你可以将它们用于通过 kubeadm join 命令将其他节点加入到集群中。

这些节点将会成为集群的工作节点，与控制平面节点协同工作。

Kubernetes 中的令牌 (token) 在集群中用于节点加入过程的身份认证和安全通信。这些令牌由 kubeadm 或管理员生成，并用于在新节点首次联系 Kubernetes API Server 时进行身份验证。

Kubernetes 令牌是集群加入过程中的关键组成部分，它们帮助确保新节点的身份得到验证，并确保集群的安全性。

  1. 加入令牌 (Join Token): 在使用 kubeadm init 初始化控制平面节点后，它会生成一个加入令牌 (Join Token)。这个令牌包括一个令牌字符串和一个哈希值。新节点需要提供这个令牌和哈希值，以便加入到集群中。通过运行 kubeadm join 命令并提供正确的令牌，新节点可以成功加入集群。

  2. 预共享密钥 (Pre-shared Key): 加入令牌的哈希值是通过使用预共享密钥计算生成的。这个密钥存储在控制平面节点上，新节点通过令牌中的哈希值和控制平面节点上的密钥进行匹配，从而实现身份验证。这确保了只有具有有效令牌和正确密钥的节点才能加入集群。

  3. 有效期: 令牌通常具有一定的有效期，过期后将无法使用。这是为了安全考虑，以确保令牌不会永久存在，从而降低潜在的风险。

  4. 令牌轮换: 在一些情况下，管理员可能需要轮换令牌，以提高集群的安全性。kubeadm 提供了命令来生成新的令牌并轮换现有令牌。

其他几个可用的工具包括：

kubeadm config: 这个命令用于生成和修改 kubeadm 的配置文件，这些配置文件包括初始化集群和加入节点时使用的配置。通过 kubeadm config 命令，你可以生成初始化或加入节点所需的配置文件，然后对其进行自定义修改。这使得在不同的部署环境中更容易地配置 Kubernetes 集群。

例如，你可以使用 kubeadm config print init-defaults 命令来生成初始化集群所需的默认配置文件，并在需要时进行修改。

kubeadm upgrade: 这个命令用于执行 Kubernetes 集群的升级操作。Kubernetes 的升级通常涉及到控制平面组件 (Control Plane) 和工作节点 (Worker Node) 的升级。kubeadm upgrade 命令提供了一种升级路径，可用于在不中断生产工作负载的情况下将集群升级到新版本。

升级过程通常包括以下步骤：

  • 升级控制平面组件。
  • 升级 kubeadm 工具本身。
  • 升级工作节点。

kubeadm upgrade 命令可用于管理这些升级步骤，使升级过程更加平滑。

kubeadm reset: 这个命令用于将节点恢复到初始状态，即将节点上的 Kubernetes 组件和配置删除，从而卸载 Kubernetes。这在需要重新部署或卸载节点时非常有用。运行 kubeadm reset 将清除节点上的所有 Kubernetes 配置和数据。

请注意，kubeadm reset 只用于卸载 Kubernetes，并不会卸载容器运行时、操作系统组件或其他可能在节点上存在的软件。

2.集群组件运行模式​

Kubernetes 集群可部署为三种部署模式或运行方式。

  • 独立组件模式：Master各组件和Node各组件直接以守护进程方式运行于节点之上，以二进制程序部署的集群隶属于此种模式。

  • 静态pod模式：控制平面的各组件以静态Pod对象形式运行在Master主机之上，而Node主机上的kubelet 和Docker 运行为系统级守护进程，Kube-proxy托管于集群上的DaemonSet控制器。

以下是静态 Pod 的一些关键特点和用途：

由 kubelet 管理：静态 Pod 是由 kubelet 直接管理的，而不是通过 Kubernetes API Server 和控制器来管理。kubelet 会定期检查节点上特定目录中的静态 Pod 配置文件，并启动/停止相应的容器来维护这些 Pod。

节点级别的应用程序：静态 Pod 通常用于运行与节点相关的应用程序，例如容器化的监控代理、网络插件、日志收集器等。这些应用程序对整个节点的性能和资源利用具有重要影响，因此它们通常以静态 Pod 的方式运行。

配置文件位置：静态 Pod 的配置文件通常存储在节点上的 /etc/kubernetes/manifests 目录下。kubelet 会监视该目录并启动 Pod。每个配置文件对应一个静态 Pod。

不受控制器管理：与常规 Pod 不同，静态 Pod 不受 ReplicationController、Deployment 或其他控制器的管理。这意味着它们不会受到控制器的自动伸缩或滚动升级的影响。

用途示例：一些常见的静态 Pod 用途包括运行网络插件（如 Flannel、Calico）、容器运行时（如 Docker 或 Containerd）、kube-proxy（用于服务代理）等。

  • 自托管 self-hosted模式：类型于第二种模式，但控制平面的各组件运行为Pod对象非静态，并且这些Pod 对象同样托管运行在集群之上，同样受控于DaemonSet类型控制器。

使用Kubeadm部署Kubernetes 集群可运行为第二种或第三种模式，默认为静态Pod 对象模式，当需要使用自托管模式时，可使用Kubeadm init 命令的 --features-gates=selfHosting 选项激活。

--feature-gates=selfHosting 是Kubernetes 中的一个特性门标志（Feature Gate），用于启用或禁用特定的实验性或高级功能。特性门标志允许用户在 Kubernetes 中启用或禁用不同的功能，并且这些功能可能还没有被广泛测试或稳定。

3.kubeadm inti 工作流程​

kubeadm 快速部署一个新的 Kubernetes 集群通常需要两个主要步骤: 在Master节点上运行Kubeadm join命令初始化控制平面,在其他节点上运行kubeadm join 命令逐一加入控制平面，进而成为集群成员。

kubeadm init 命令在内部分为多个阶段，每个阶段执行不同的任务，以确保集群的顺利初始化。

各阶段的简要说明如下：

阶段名称阶段任务
preflight初始化前的环境检查，在这个阶段，kubeadm 将检查主机上的一系列预定义条件，以确保它们满足 Kubernetes 的最低要求。
这些条件包括操作系统、内核参数、容器运行时等。
kubelet-start生成kubelet 配置，其中包含了与控制平面的通信信息，如 API Server 的地址和端口，以及与其它 kubelet 节点的通信信息。kubelet 配置文件通常存储在 /etc/kubernetes/ 目录下。 接下来启动或重启kubelet以便于静态Pod运行各服务组件。kubeadm 还会等待初始化 Token 的生成，初始化 Token 是用于后续节点加入集群的凭据。
certs生成各种数字证书，用于确保集群通信的安全性和认证；
1.**CA 证书（Certificate Authority Certificate）**CA 证书是整个证书链的根证书，用于签发其他数字证书。kubeadm 在初始化集群时会生成一个根 CA 证书，用于签发后续组件的证书。
2.API Server 证书：API Server 证书用于加密和认证 Kubernetes 控制平面组件的通信。它通常由根 CA 证书签发，控制平面组件使用该证书来与客户端（如 kubectl、kubelet、应用程序）进行安全通信。
3.Front Proxy 证书：Front Proxy 证书用于加密和认证前端代理（front proxy）的通信。在 Kubernetes 中，前端代理是一个反向代理，用于处理集群中的控制平面请求。
4.etcd 证书：etcd 证书用于加密和认证 etcd 集群的通信。etcd 是 Kubernetes 集群的数据存储后端，用于存储集群状态和配置信息。
kubeadm 在初始化集群时会生成这些证书，并将它们分发给各个组件，以便它们能够在安全的环境中运行。
kubeconfigkubeconfig 阶段用于生成与集群和控制平面组件相关的 kubeconfig 文件。
1.kube-apiserver kubeconfig: 该文件包含 API Server 的地址和端口，以及与授权和身份验证相关的配置信息。
2.kube-controller-manager kubeconfig：该文件包括控制器管理器的监听地址以及与 API Server 进行身份验证所需的信息。
3.kube-scheduler kubeconfig： 该文件包括调度器的监听地址以及与 API Server 进行身份验证所需的信息。
4.kubelet kubeconfig： 该文件包含 kubelet 与 API Server 通信所需的配置信息，包括 API Server 的地址和与之通信的证书和密钥。
5.admin kubeconfig： 该文件包括 API Server 的地址和端口，以及用于身份验证的客户端证书和密钥。
这些 kubeconfig 文件是控制平面组件和管理员连接到集群的关键。kubeadm 在 kubeconfig 阶段生成这些文件，并通常将它们存储在 /etc/kubernetes/ 目录中。管理员可以使用这些 kubeconfig 文件配置 kubectl 命令行工具，以便与集群进行通信和管理。
control-plane该阶段会生成控制平面组件（kube-apiserver、kube-controller-manager 和 kube-scheduler）的静态 Pod 配置清单。这个配置清单包括了 kube-controller-manager 的命令行参数、监听地址、证书文件路径等信息，以及其他与控制器相关的配置。
etcdetcd 阶段用于生成本地 etcd 的静态 Pod 配置清单。这个配置清单用于将 etcd 作为一个静态 Pod 运行在控制平面节点上，负责存储集群的状态和配置信息。其中包括 etcd 的监听地址、证书和密钥文件路径、数据存储目录等信息。配置文件通常位于 /etc/kubernetes/manifests/ 目录下，命名为 etcd.yaml 或类似的文件名。一旦静态 Pod 清单被生成并存储在正确的位置，kubelet 将检测到它，并自动启动。etcd 静态 Pod 运行后，它会将集群的状态和配置信息存储在指定的数据存储目录中，通常默认情况下是 /var/lib/etcd。
upload-config该阶段的关键目标是将 kubeadm 和 kubelet 配置信息以一种集中化的方式存储在集群中，以便各个组件和节点能够共享和使用这些配置。这些配置在集群初始化过程中至关重要，因为它们决定了控制平面组件和节点如何连接和交互。通常情况下，这些 ConfigMap 资源存储在 kube-system 命名空间中，并具有特定的命名约定，以便其他组件能够轻松找到和使用它们。kubeadm 会生成的 ConfigMap，中包含了与初始化集群相关的配置信息，如 API Server 的地址和端口、证书和密钥的路径、初始化 Token 等。kubelete 也会生成一个 ConfigMap，其中包含了与 kubelet 相关的配置信息，如 kubelet 的 kubeconfig 文件内容、Pod 网络的配置信息等。
upload-certs该阶段是初始化 Kubernetes 集群过程中的一个关键步骤，它负责将与集群安全性相关的证书文件上传到集群中，并创建一个名为 kubeadm-certs 的 ConfigMap 资源对象来存储这些证书，证书通常存储在 kube-system 命名空间中，以确保集群中的其他组件和后续加入的其他Master节点可以访问这些证书，用于控制平面组件和节点之间的安全通信和身份验证。
mark-control-plane该阶段的主要目的是将节点标记为控制平面节点，并确保节点具备运行控制平面组件的能力。标记的节点将被集群认可为 Master 节点，这个标记告诉 Kubernetes 集群，当前节点具有控制平面组件的角色，可以运行 API Server、Controller Manager、Scheduler 等控制平面组件。并为该节点设置node-role.kubernetes.io/master:NoSchedule 污点，防止其他工作负载Pod运行在当前节点上。kubeadm 会将控制平面节点的信息存储在 /etc/kubernetes/cloud-config 目录下的 kube-controller-manager 和 kube-scheduler 配置文件中，以便这些组件可以识别和管理控制平面节点。
bootstrap-token该阶段用于生成引导令牌（bootstrap token），这些令牌允许新的节点加入 Kubernetes 集群的控制平面。引导令牌包含一些重要信息，如令牌的密钥、有效期限、用途等，它们允许新节点基于预共享的密钥与集群中的控制平面节点建立连接并获得身份认证。

bootstrap-token 阶段的主要功能和操作：
1.生成引导令牌：会生成引导令牌，这是一个用于授权新节点加入集群的令牌。令牌通常包括一个密钥和一些元数据，以便集群可以识别和验证该令牌。
2.设置令牌有效期：引导令牌通常具有一个有效期，kubeadm 可以配置这个有效期，以限制令牌的使用时间。一旦令牌过期，它将不再被接受。
3.指定令牌用途：引导令牌可以配置为特定用途，例如用于加入节点、重置集群等。不同的令牌用途可能具有不同的权限和限制
4.保存令牌信息:kubeadm 会保存生成的令牌信息，通常在节点上的某个文件中，以便新节点可以访问这些信息。
5.提供令牌给新节点: 新节点需要具有生成的引导令牌信息才能加入集群。这些信息通常包括令牌字符串、CA 证书等。 新节点可以使用这些信息来与集群中的控制平面节点建立连接，完成节点加入过程。
kubelet-finalizekubelet-finalize 阶段的目标是确保 kubelet 在初始化后能够正确配置，以便它可以安全地连接到集群的控制平面，并开始管理节点上的容器和 Pod。在 TLS 引导阶段，kubelet 被配置为使用安全的连接与集群的控制平面通信。而在 kubelet-finalize 阶段，进一步更新 kubelet 的配置，确保其与集群的其他部分协同工作。这个更新会包括与控制平面的安全连接所需的信息，如 API Server 的地址和证书信息。除了更新 kubeconfig 文件之外，kubelet 的启动参数也可能需要调整。这些参数通常包括 API Server 地址、证书文件路径、密钥文件路径等。在配置更新完成后，通常需要重启 kubelet 服务，以使新的配置生效。
addon该阶段的主要任务是确保核心附加组件在集群中正确安装、配置和运行。这些组件对于集群的网络功能和 DNS 解析功能至关重要，它们允许 Pod 之间进行通信和发现，并提供了 Kubernetes 服务的负载均衡功能。安装和配置这些组件是 Kubernetes 初始化过程的重要一部分，确保集群的网络和 DNS 服务正常工作。

4.kubeadm join 工作流程​

环境预检

kubeadm join 命令也需要进行环境预检操作，确定所在节点满足可加入集群中的前提条件。

这类关键检测的步骤包括：

  • Kubernetes 版本匹配：kubeadm join 会检查所在节点上的 Kubernetes 组件版本是否与控制平面节点上的版本匹配。版本不匹配可能导致问题。
  • 操作系统支持：kubeadm join 确保所在节点使用的操作系统是 Kubernetes 支持的操作系统之一。通常，Kubernetes 支持多种 Linux 发行版。
  • Docker 或容器运行时支持：kubeadm join 检查所在节点上是否安装了 Docker 或其他容器运行时，并验证其版本是否与 Kubernetes 兼容。
  • 网络插件支持：如果您的集群使用了网络插件（如 Calico、Flannel 等），kubeadm join 确保已安装并配置了适当的网络插件。
  • 授权检查：确保新节点有权加入集群。通常，kubeadm join 命令需要提供有效的加入令牌（Join Token）以进行身份验证。
  • 网络互通性：kubeadm join 会验证新节点是否可以与集群中的控制平面节点建立网络连接。这包括检查 API Server 的可访问性。
  • 证书和密钥检查：确保节点上存在必要的证书和密钥文件，以便安全地连接到集群。
  • 操作系统设置检查：检查所在节点的操作系统设置，例如防火墙规则、SELinux 设置等，以确保它们不会阻止必要的通信。

同控制平面建立双向信任关系

与控制平面建立双向信任关系是新节点加入 Kubernetes 集群的关键一步。这一信任关系的建立通过证书和令牌进行身份验证，确保新节点和集群的控制平面能够互相信任和安全地通信。

双向信任建立的过程可以分为两个主要阶段：发现阶段和 TLS 引导阶段。

1.发现阶段：

在发现阶段，新节点请求加入集群，通常使用一个特定的令牌（共享令牌 Bootstrap Token）。这个令牌由集群管理员或初始化控制平面节点生成，新节点使用令牌向指定的API Server发送请求以获取集群信息。

2.TLS 引导阶段：

Bootstrap Token 主要用于节点确定 API Server 的身份，以进行加入请求的授权。它确保了节点具有加入集群的权限，但在数据传输过程中，并没有提供数据的加密和验证数据真实性。为了确保数据在传输过程中的安全性，TLS 引导程序阶段起到了关键作用。

在 TLS 引导程序阶段，控制平面通过 TLS Bootstrap 机制为新节点签发数字证书，这个证书用于加密通信和验证数据的真实性。这确保了新节点与控制平面之间的通信是安全的，同时确保了数据不会被篡改。

TLS 引导程序的主要步骤包括：

  1. 证书签发：kubelet 通 TLS Bootstrap 使用共享令牌向API Server 进行身份验证后提交证书并签署请求（CSR）,随后控制平面自动签署该请求从而生成数字证书。
  2. 证书传输：控制平面节点通过安全的 TLS 连接将签发的证书传输给新节点。
  3. 配置新节点：新节点接收到证书后，将其保存在本地，并配置节点的 kubelet、kube-proxy 等组件，以使用这些证书与控制平面节点建立安全连接。

5.部署分布式Kubernetes 集群​

5.1 基础环境设置​

  • 系统版本：Ubuntu 18.04.6
  • 容器运行时引擎：Docker 19.03.15
  • Kubernetes: v1.19

https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/18.04.6/

IP 地址主机名角色
10.1.0.110k8s-master01 k8s-master01.ilinux.io k8s-api.ilinux.iomaster
10.1.0.111k8s-node01 k8s-node01.ilinux.ionode
10.1.0.112k8s-node02 k8s-node02.ilinux.ionode
10.1.0.113k8s-node03 k8s-node03.ilinux.ionode

5.1.1 主机时间同步​

#设置时区
timedatectl set-timezone Asia/Shanghai


#安装chrony
#三节点安装
apt install chrony -y


##服务端配置
vim /etc/chrony/chrony.conf
pool time1.aliyun.com      iburst maxsources 1
allow all

systemctl start chrony
systemctl enable chrony

5.1.2 Hosts​

10.1.0.110 k8s-master01 k8s-master01.ilinux.io k8s-api.ilinux.io
10.1.0.111 k8s-node01 k8s-node01.ilinux.io
10.1.0.112 k8s-node02 k8s-node02.ilinux.io
10.1.0.113 k8s-node03 k8s-node03.ilinux.io
systemctl stop ufw && systemctl disable ufw

swapoff -a

5.1.3关闭swap和SElinux​

swapoff -a | sed -i '/swap/d' /etc/fstab
vim /etc/selinu/config
disable
swapoff -a | sed -i '/swap/d' /etc/fstab
vim /etc/selinu/config
disable

5.1.4 修改内核参数​

在 Kubernetes (K8s) 集群上，为了优化性能、安全性和容器工作负载的稳定性，您可能需要修改 Linux 内核参数。以下是一些常见的内核参数，以及如何进行修改：

sysctl 配置文件：sysctl 是用于修改和查询内核参数的工具。您可以通过修改 sysctl 配置文件来永久更改内核参数。配置文件通常位于 /etc/sysctl.conf 或 /etc/sysctl.d/ 目录中。例如，要增加 TCP 连接的最大数量，可以在配置文件中添加以下行：

vim /etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65000
sysctl -p

然后，使用 sysctl -p 命令重新加载配置。

ulimit 设置：通过修改用户的 ulimit 设置，您可以更改每个进程可以打开的文件描述符数、进程数等。这可以通过修改 /etc/security/limits.conf 文件实现。

vim /etc/security/limits.conf
*   soft    nofile   65536
*   hard    nofile   65536
ulimit -a
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sysctl -p  /etc/sysctl.d/k8s.conf
  • net.bridge.bridge-nf-call-ip6tables = 1：允许 IPv6 数据包通过 iptables 进行处理，这对于容器网络通信非常重要。
  • net.bridge.bridge-nf-call-iptables = 1：允许 iptables 处理桥接的数据包，这对于容器网络和服务发现也很重要。
  • net.ipv4.ip_forward = 1：启用 IPv4 数据包的转发，这对于在 Kubernetes 集群中进行路由和流量管理很重要。
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sysctl -p  /etc/sysctl.d/k8s.conf

5.2 配置容器运行时引擎​

apt update
apt install -y apt-transport-https ca-certificates \
curl gnupg-agent software-properties-common

添加Docker 官方GPG 证书，以验证程序包签名

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

添加稳定版本的Docker-CE 仓库

add-apt-repository \
"deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \
$(lsb_release -cs) stable"

在生产系统上，可能会需要应该安装一个特定版本的Docker CE，而不是总是使用最新版本： 列出可用的版本：

sudo apt update 
root@k8s-master01:/sh# apt-cache madison docker-ce
 docker-ce | 5:24.0.2-1~ubuntu.18.04~bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:24.0.2-1~ubuntu.18.04~bionic | https://mirrors.aliyun.com/docker-ce/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:24.0.1-1~ubuntu.18.04~bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:24.0.1-1~ubuntu.18.04~bionic | https://mirrors.aliyun.com/docker-ce/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:24.0.0-1~ubuntu.18.04~bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:24.0.0-1~ubuntu.18.04~bionic | https://mirrors.aliyun.com/docker-ce/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:23.0.6-1~ubuntu.18.04~bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:23.0.6-1~ubuntu.18.04~bionic | https://mirrors.aliyun.com/docker-ce/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:23.0.5-1~ubuntu.18.04~bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:23.0.5-1~ubuntu.18.04~bionic | https://mirrors.aliyun.com/docker-ce/linux/ubuntu bionic/stable amd64 Packages
 docker-ce | 5:23.0.4-1~ubuntu.18.04~bionic | https://download.docker.com/linux/ubuntu bionic/stable amd64 Packages

更新apt索引后安装Docker-ce

 sudo apt install docker-ce=5:19.03.15~3-0~ubuntu-bionic docker-ce-cli=5:19.03.15~3-0~ubuntu-bionic containerd.io=1.5.11-1 -y

**自定义docker配置 **

vim /etc/docker/daemon.json

{
    "exec-opts": ["native.cgroupdriver=systemd"],
    "log-driver": "json-file",
    "log-opts":{
       "max-size": "100m"
},
"storage-driver": "overlay2",
"registry-mirrors": ["https://sqytbycc.mirror.aliyuncs.com"]
}
  • exec-opts 配置了 CGroup 驱动程序，将其设置为 "systemd"，这是许多现代 Linux 系统上的推荐设置。
  • log-driver 配置了容器日志驱动程序，将其设置为 "json-file"，表示容器的日志将以 JSON 格式记录在文件中。
  • log-opts 用于配置日志选项，其中 max-size 设置容器日志文件的最大大小为 "100m"，即 100 兆字节。
  • storage-driver 配置了 Docker 存储驱动程序，将其设置为 "overlay2"，这是常见的存储驱动程序之一，用于管理容器的文件系统层
systemctl daemon-reload && systemctl restart docker && systemctl enable docker

5.3 安装kubeadm、kubelet 和kubectl​

添加kubernetes 官方程序密钥：

curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add -

为apt添加kubernetes程序包仓库

vim /etc/apt/sources.list

echo deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main >> /etc/apt/sources.list && apt update

软件包版本：

  • "kubernetes-xenial" 的软件包版本可能与 Ubuntu 16.04 中的软件包版本相匹配。
  • "kubernetes-bionic" 的软件包版本可能与 Ubuntu 18.04 中的软件包版本相匹配。

支持周期：

  • "kubernetes-xenial" 针对 Ubuntu 16.04，已于 2021 年 4 月结束官方支持，不再收到常规更新。
  • "kubernetes-bionic" 针对 Ubuntu 18.04，官方支持周期较长，支持至 2023 年 4 月

5.3.1 更新软件包索引并安装程序包​

apt update 
#查看可用版本
apt-cache madison kubelet
#选择 1.19.16-00 版本

apt install -y kubelet=1.19.16-00 kubeadm=1.19.16-00 kubectl=1.19.16-00
sudo systemctl enable kubelet && sudo systemctl start kubelet

5.3.2 初始化控制平面​

sudo kubeadm init \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.19.16 \
--control-plane-endpoint k8s-api.ilinux.io \
--apiserver-advertise-address 10.1.0.110 \
--pod-network-cidr 10.244.0.0/16 \
--token-ttl 0

--image-repository 指定要使用的镜像仓库，这里使用的是阿里云的，默认为gcr.io

--kubernetes-version kubernetes 程序组件的版本号，他必须与安装的kubelet 程序包的版本相同。

--kubernetes-version 控制平面的固定访问端点，可以是IP地址或DNS 名称，作为集群管理员与集群组件的kubeconfig配置文件的API Server 的访问地址。单控制面板部署时可以不使用该选项。

--apiserver-advertise-address API Server 通告给其他组件的IP地址，一般为Master节点用于集群内通信的IP地址，0.0.0.0 表示节点上所有可用地址。

--pod-network-cidr Pod 网络的地址范围，用于容器间通信的 IP 地址段，通常Flannel 网络插件的默认值为10.244.0.0/16，Project Calico 插件的默认值为 192.168.0.0/16。

--service-cidr Service 的网络地址范围，默认为10.96.0.0/12。通常仅Flannel一类的网络插件需要手动指定该地址。

--token-ttl 共享令牌的过期时长，默认为24小时，0表示永不过期。 为防止不安全的存储等原因导致令牌泄露危及集群安装，建议为其设定过期时长。

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of control-plane nodes by copying certificate authorities
and service account keys on each node and then running the following as root:

  kubeadm join k8s-api.ilinux.io:6443 --token 60jbc3.cse8z5eiqgdtt1nf \
    --discovery-token-ca-cert-hash sha256:252d584d53ef359d98219cabcd9d7cb07b3c898058d1045e3feeaf5773585ba6 \
    --control-plane

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join k8s-api.ilinux.io:6443 --token 60jbc3.cse8z5eiqgdtt1nf \
    --discovery-token-ca-cert-hash sha256:252d584d53ef359d98219cabcd9d7cb07b3c898058d1045e3feeaf5773585ba6

vim /etc/profile
source <(kubectl completion bash)


source /etc/profile

5.3.3 配置命令行工具​

kubectl 是 Kubernetes 集群的最常用命令行工具，它默认搜索当前用户主目录（保存于环境变量HOME中的值）中名为.kube 的隐藏目录，定位其中名为config 的配置文件以读取必要的配置。包括要接入Kubernetes 集群以及用于集群认证的证书或令牌等信息。

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubeconfig 文件通常包括以下信息：

  • cluster：描述了要连接的 Kubernetes 集群的名称、API 服务器的地址和证书信息。
  • user：定义了用于身份验证的用户信息，通常包括用户名和证书。
  • context：将 cluster 和 user 关联在一起，并指定默认上下文。
  • current-context：指定默认使用的上下文，这决定了用户与集群的交互。

/etc/kubernetes/admin.conf 通常用于控制平面管理操作，如部署、管理和监视集群的操作。这个配置文件是敏感的，应该受到保护，只允许有权限的用户访问。

用户可在任何能够通过k8s-api.ilinux.io 与 API Server 通信的主机上安装Kubectl，并为其复制或生成的kubeconfig文件以访问控制平面。

5.4 部署 Flannel 网络插件​

通过执行kubectl get node 命令获取集群节点相关状态信息，出现NotReady状态是因为集群中未部署网络插件所致。

root@k8s-master01:~# kubectl get node
NAME           STATUS     ROLES    AGE     VERSION
k8s-master01   NotReady   master   9m37s   v1.19.16

较为流行的为K8S提供Pod网络的插件有 Flannel、Calico和WeaveNet 等。相较来说Flannel以其简单、模式丰富、易部署、易使用等特性颇受用户欢迎。

Flannel同样可运行为K8S的集群附件，用DaemonSet控制器为每个节点（包括Master）运行一个Pod实例。

flannel项目地址

Deploying Flannel with kubectl

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

If you use custom podCIDR (not 10.244.0.0/16) you first need to download the above manifest and modify the network to match your one.

命令结果显示Pod的状态为Running时表示网络插件Flannel部署完成。

root@k8s-master01:/yaml# kubectl get pods -n kube-flannel | grep flannel
kube-flannel-ds-sbwf9   1/1     Running   0          93s

当前节点状态也转为Ready状态。

root@k8s-master01:/yaml# kubectl get node
NAME           STATUS   ROLES    AGE   VERSION
k8s-master01   Ready    master   24m   v1.19.16

5.5 添加工作节点​

当主机基础环境准备好后可使用Kubeadm join命令加入集群，该命令需要借助共享令牌进行首次与控制平面通信时的认证操作。相关的令牌信息及完成的命令由初始化控制平面的命令结果得出。

kubeadm join k8s-api.ilinux.io:6443 --token 8pq5xn.waqfh238255rpvwl \
    --discovery-token-ca-cert-hash sha256:c204bc29c51c0df7e79b2a2dd1b49b89f3c5152189cb4f6f26c8c82dc525fa56
root@k8s-node02:~# kubeadm join k8s-api.ilinux.io:6443 --token 8pq5xn.waqfh238255rpvwl \
>     --discovery-token-ca-cert-hash sha256:c204bc29c51c0df7e79b2a2dd1b49b89f3c5152189cb4f6f26c8c82dc525fa56
[preflight] Running pre-flight checks
        [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.